home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / July 96 / Polygon shapes < prev    next >
Encoding:
Internet Message Format  |  1996-08-01  |  3.6 KB  |  [TEXT/ttxt]
  1. Subject:     Polygon shapes
  2. Sent:        7/23/96 12:09 PM
  3. Received:    7/23/96 12:20 PM
  4. From:        Brian Arnold, arnold@lumina.com
  5. Reply-To:    ODF Interest, ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
  7.  
  8. Howdy ODF-ers,
  9.  
  10. Since my ODF Draw-derived part needed polygon shapes, I patched together a
  11. polygon shape class and a hexagon shape subclass for testing.  I'm not
  12. proud of it, but it works well enough for a demo.  Send me e-mail if you
  13. want the sources (there isn't much source, mostly headers ;-).  Feel free
  14. to provide feedback (before I go off defining more subclasses for my
  15. part...).
  16.  
  17. Here are some notes I kept while writing it.  It took about a day to write,
  18. graft into my Draw (er, Sketch) part, and test.
  19.  
  20. o) I would pummel the person who decided OpenDoc will use fixed point
  21. numbers.  The reason is, you can't "just use them" with literals.  I took a
  22. six-of-one approach, coercing FW_IntToFixed on my literals, then noted ODF
  23. sometimes takes a half-a-dozen-of-the-other approach, converting FW_Fixeds
  24. into ints, doing math with literals, then converting back to FW_Fixeds.
  25. "Sheesh" is all I can say.
  26.  
  27. o) There is incomplete support for polygons in ODF 1; here's a key function
  28. I identified as missing (included as a static fn in my PolyShp.cpp file):
  29.  
  30. //--------------------------------
  31. //      FW_CreatePolygonODShape
  32. //  !!! Missing from FWGrUtil.cpp
  33. //--------------------------------
  34.  
  35. static ODShape* FW_CreatePolygonODShape(
  36.         Environment *ev,
  37.         unsigned long pointCount,
  38.         const FW_SPoint* pointArray)
  39. {
  40.   ODShape* shape = ::FW_NewODShape(ev);
  41.   ::FW_SetShapeRegion(ev, shape, ::FW_CreatePolygonRegion(pointCount,
  42.                                         pointArray));
  43.   return shape;
  44. }
  45.  
  46. o) The private ODF representation for a Polygon effectively requires that
  47. its points fCount be initialized once and not changed.  It would be more
  48. convenient if SetPoints() could adjust the fCount and adjust the memory
  49. pointed to by fPoints instead of throwing an assertion when SetPoints sets
  50. more points than fCount.
  51.  
  52. o) Although the ODF Polygon shape renderer has an autoCloseFrame parameter,
  53. when I drag my polygon shapes without a closed polygon (the OD polygon
  54. shape I assume), they are are outlined screwy.  I had to make sure my
  55. Hexagon shape subclass includes the first point as the last point even
  56. though the parent class Polygon shape uses autoCloseFrame as true and draws
  57. correctly without the last point.  Did I misunderstand this parameter's
  58. purpose, or is there a defect/limitation in the OpenDoc polygon
  59. representation?
  60.  
  61. o) I had initially copied the OvalShp sources as a template for developing
  62. the PolyShp and HexShp sources, and I noticed these very simple shapes
  63. files pull in a lot of headers that don't appear to be needed.  How much of
  64. this is necessary?
  65.  
  66. o) There are ODF <blah-blah> shapes (derived from FW_TGrRefPtr), and ODF
  67. <blah-blah>Shape shapes (derived from FW_CShape), the latter which look
  68. similar to the ODF Draw shape types.  What is the relationship between all
  69. of these?  Should ODF Draw (and hence my code as well) eventually be using
  70. the FW_CShapes instead of defining its own parallel representations?
  71.  
  72. o) Finally, a thank-you to those who worked on shapes in ODF and ODF Draw:
  73. I found them generally easier to work with and much more powerful than the
  74. MacApp shape code in my existing app, despite the very minor issues listed
  75. above.
  76.  
  77. - Brian
  78.  
  79. ---------------------------------------------------------------
  80. Brian Arnold                                  arnold@lumina.com
  81. Director of Software Development
  82. Lumina Decision Systems, Inc.            http://www.lumina.com/
  83.  
  84.  
  85.